User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 I am accessing my google mail account via IMAP. Whenever I try to FINALLY delete a message, that message doesn't really get deleted, but ARCHIVED instead (to [gmail]\All Mail) - what I don't want. I want to delete that message FINALLY ! This problem always happens when I am A) highlighting a message in TB's threadpane - irrespective of the kind of folder (e. g. "[gmail]\sent") - and pressing [shift] + [del]. B) setting e. g. the folder "[gmail]/sent" in TB to automatically delete messages that are older than e. g. 30 days (= folder properties in TB). You can find out, that these messages (case A and B) are really getting archived instead of getting finally deleted, when go to GMail's website and set a message filter (test filter) for -in:inbox -in:drafts -in:sent -is:muted These criteria will show you all archived mails. And these archivied mails will equal all messages you originally finally deleted (via case A and B). Reproducible: Always

> Whenever I try to FINALLY delete a message, that message doesn't really get > deleted, but ARCHIVED instead (to [gmail]\All Mail) - what I don't want. Currently, nothing is moved to [Gmail]/All Mail. Any active mail(mail which is not held in [Gmail]/Trash nor [Gmail]/Spam) is held in [Gmail]/All Mail since initial, and an active mail is deleted from [Gmail]/All Mail only when a mail is copied(or moved) to [Gmail]/Trash or [Gmail]/Spam. "Move to [Gmail]/All Mail" happens only when a mail is moved back from [Gmail]/Trash(or [Gmail]/Spam) to IMAP folder other than [Gmail]/Trash and [Gmail]/Spam. Read and understand at least following Gmail Help documents, > https://mail.google.com/support/bin/answer.py?hl=en&answer=77657 > https://mail.google.com/support/bin/answer.py?hl=en&answer=78755 which are pointed by next document, > http://kb.mozillazine.org/Using_Gmail_with_Thunderbird_and_Mozilla_Suite#Gmail_IMAP_Instruction_Manuals before post complaints on Gmail IMAP at bugzilla.mozilla.org, please. See also bugs listed in dependency tree for meta bug 402793, with "Show Resolved", please. Our recommendation is; - Folder specified at IMAP delete model of "Move to:" = [Gmail]/Trash => "Empty Trash" is done on this folder. Note: Currently, [Gmail]/Trash is always used regardless of this setting. - IMAP delete model = Remove immediately, to remove only Gmail Label(==IMAP folder name) from a mail by "Delete", to avoid automatic deletion from [Gmail]/Trash after 30 days by Gmail. - If a mail is needed to be permanently erased, copy(or move) a mail to [Gmail]/IMAP explicitely. - If mails in [Gmail]/Trash are to be permanently erased immediately instead of after 30 days, execute "Empty Trash" or "Select+All and Shift+Delete" at [Gmail]/Trash.

Phenomenon of "deleted mail doesn't automatically go to [Gmail]/Trash with IMAP delete model of 'Move to trash', without appropriate settings by user which is required setting for using Gmail IMAP" is already morphed to issue of "move target folder for delete other than [Gmail]/Trash is impossible to use with IMAP delete model of 'Move to trash'"(bug 610667), by enhancement of "XLIST command support" and change of "always use trash returned by XLIST([Gmail]/Trash if Display Language: of Gmail is English(US)), regardless of trash folder selection at 'Move to trash' model". Closing as WORKSFORME.

Re comment 2: As far as I understand, bug 610667 describes a problem with the deletion model "Move to trash" within Thunderbird's Account-Settings for Gmail. However my original problem descriptions A) and B) (see comment 0) were, that in the following two cases mails are archived instead of immediately and finally deleted: > A) highlighting a message in TB's threadpane - irrespective of the kind of > folder (e. g. "[gmail]\sent") - and pressing [shift] + [del]. --> this only concerns a single message that is manually deleted via [shift]+[del] > B) setting e. g. the folder "[gmail]/sent" in TB to automatically delete > messages that are older than e. g. 30 days (= folder properties in TB). --> this concerns a single folder and its folder properties for automatic deletion after x days; it doesn't concern TB's general account settings for "momve to trash" etc. In fact in both cases A) + B), I don't want the mails to be moved to any folder (neither [gmail]/trash, nor [gmail]/all mails nor any other folder). I just want to get rid of them immediately and finally - as it would be if I would use a POP3 account instead of (Gmail-)IMAP. So from my point of view, this is not covered by bug 610667. But I would understand if you would say, that this is all a problem of Gmail's Label-System and not a bug in TB. Then I would have to wait until Gmail offers real folders instead of Labels one day, what hopefully will solve my problems then. For the time being, the only solution for me is not to do what I described in A) + B) - what I also learned from the final section of your comment 1.

(In reply to comment #3) > In fact in both cases A) + B), I don't want the mails to be moved to any folder > (neither [gmail]/trash, nor [gmail]/all mails nor any other folder). As I wrote before, any mail in other than [Gmail]/Trash and [Gmail]/Spam is always placed in [Gmail]/All Mail by *Gmail* since initial of the mail. No mail is moved to [Gmail]/All Mail, except when copy/move back from [Gmail]/Trash or [Gmail]/Spam. > I just want to get rid of them immediately and finally - as it would be if I > would use a POP3 account instead of (Gmail-)IMAP. You are using Gmail and Gmail IMAP. You have to read at least instruction manual of Gmail/Gmail IMAP, as you do when you start to use digital camera or mobile phone. > So from my point of view, this is not covered by bug 610667. You are right. That bug is absolutely different from your complaint of comment #0. That bug simply has relation to this bug because phenomenon you stated in comment #0 will come back if bug 610667 will be resolved. > this is all a problem of Gmail's Label-System and not a bug in TB. Right. But current biggest problem is "confusions of users due to the Gmail's Label-System. If understanding like next, current Gmail IMAP is not so bad. (a) Real folders are: [Gmail]/All Mail, [Gmail]/Spam, [Gmail]/Trash only. (b) All other IMAP folders(Gmail Label) are a kind of Virtual Folder of Tb, which has search criteria of (Tag for Tb is equal to Gmail Label==folder name via Gmail IMAP"), with search target folder is [Gmail]/All Mail. (c) To delete old version of draft mail(deleted draft mail) permanently istead of merely removing Gmail Label, Gmail moves deleted draft mail to Trash([Gmail]/Trash via Gmail IMAP) automatically. (d) To make "undo delete like operation" possible by "copy/move mail in [Gmail]/Trash back to an IMAP folder(==Gmail Label) or [Gmail]/All Mail (real folder for us)", all Gmail Label added to a mail is kept for mail in [Gmail]/Trash by Gmail, if the mail is copied/moved to [Gmail]/Trash via Gmail IMAP. It's natural interpretation of Gmail's implementation(any mail is held in All Mail, Trash, or Spam, and any Gmail Label can be added to any conversation via Web or to a mail via Gmail IMAP) and Gmail IMAP's implementation(Gail IMAP presents Gmail Label as IMAP folder name to IMAP client). By your considering "IMAP folder name via. Gmail" == "Gmail Label" == "Tb's Tag of hidden attribute", Gmail IMAP will become useful for you. Annoying Gmail Label maintenance at Gmail's Web interface is replaced by easy operation of "copy/move mail between folders at mailer", with penalty of duplicated mail download at Inbox and [Gmail]/All Mail. Remaining problem is: It's impossible to know "what other Gmail Labels are added to a mail" via IMAP client. It may be resolved by "system wide UID" by Gmail IMAP. Uniqueness of UID is guranteed within an IMAP folder only by Gmail IMAP, as ordinal IMAP does. If same UID in [Gmail]/All Mail is usd for mail in Gmail Label=IMAP folder name, user can know which mails are same mail by UID. Similar "system wide UID" is probably used by Yahoo! Mail's IMAP, in order to make UID assignment simple.

working as designed ~= invalid (i.e. it never was a bug)